b. コンポーネントチームモデル
https://scrapbox.io/files/64953e3771e50c001b08d1e7.png
コンポーネントチームはアーキテクチャを中心に構成されている
全てのチームはシステムまたは技術の一部を専門とする（e.g. フロントエンドとバックエンド、 Java と C++ etc）
コンポーネントチームの利点
明確なコードと設計の所有権
table: 明確なコードと設計の所有権
メリット 代償
チームに存在意義と明確な責任を与える コードの変更は 1 チームのみ可能なため、ボトルネックが発生する。所有者がコードや設計の代替案についてフィードバックを得ることが少ない
明確な境界線（各チームは、それぞれのサンドボックスを持つ
table:明確な境界線
メリット 代償
自分たちの領域内であればなんでもできる（自分たちの作業を他のチームに妨げられない） 簡単に統合できなくなる（統合が失敗したとき、その担当が誰であったのか明らかにするのも苦痛で時間がかかる）
LeSS では、プロダクトのリスクを減らすためにプロダクト全体思考と継続的インテグレーションによって、個別のサンドボックスを不要にする
深い専門性
table: 深い専門性
メリット 代償
コンポーネントチームの欠点
これらの欠点はよく知られており、コンポーネントチームモデルで応急処置を下だけでは解決できない。解決方法はフィーチャーチームモデルへの移行のみである。
不均衡で非同期な依存関係
顧客が必要とするのは機能であり、機能には複数のコンポーネントが関わる傾向がある。これはチーム間の依存関係を引き起こす。
これらの依存関係の特徴
不均衡: A チームには多くの仕事があり、 B チームにはほとんど仕事がない
非同期: C チームが D チームに依存する仕事を持っていても、 D チームはもっと重要なアイテムを持っているのでそれに取り組まない
不均衡と非同期は深刻な調整と統合の問題を引き起こす
不均衡と非同期を解決するための典型的な解決策
より多くの計画を立てる
調整のための新しい役割を設置する
定例の進捗会議を持つ「プロジェクトチームを立ち上げる」
これらの解決策も、全て無駄である
依存関係は時間が経過しても解消されることがなく、既存のシステムの中で行うその場しのぎの対応は痛み、苦しみ、ひどいコンフリクトの原因になる
価値よりもアウトプット量への注力
技術視点での専門化によって、生産されたコードで測定されるアウトプットは増加するかもしれないが、顧客にとっての価値には直結しない
効率が機能の優先順位付けに影響する場合は特にそうなる
シーケンシャルな工程と長いリリースサイクルをもたらす
顧客の要求分析は誰が行うのか？コンポーネントチームの技術検討は誰がするのか？顧客中心の機能全体を誰が統合してテストするのか？